Many markets, such as healthcare, financial, business administration, and governmental markets, must produce publish-quality reports from predefined templates to meet client, regulatory, and other needs. Often, the markets require mass generation of reports with varying formats, requiring the use of numerous predefined templates. One solution for rendering such reports utilizes a fixed format approach. For example, a core architecture may be centered on a word processing software, in which the format for each report is represented as a template for the word processing software. Data for each report is retrieved and inserted into the template for the report using macros. However, this architecture lacks scalability, flexibility, and requires significant maintenance costs to maintain the various templates. For example, templates for different reports may contain certain common sections. When the format of each common section is built or changed, the work must be repeated for each template.
The healthcare industry is one area in particular that requires extensive record reporting and illustrates some limitations to current fixed format approaches to rendering reports. Regulations often place strict documentation requirements on healthcare facilities, such as hospitals and physician clinics. In addition, in order to provide proper care, it is essential that medical providers, such as physicians and nurses, have access to clinical charts with accurate medical information regarding patients they treat. One limitation of a current fixed format approach to rendering reports is that the templates used are often updated and previous versions of the templates are not maintained. If a clinical chart was previously created using a template that has since been updated or replaced, it may be difficult and possibly even impossible to recreate the clinical chart. The current template may produce a clinical chart that is unintelligible or incorrect as the data and template no longer correspond. For instance, the data pulled may not be located properly in the template, producing an inaccurate or incomprehensible chart.
Another limitation of some current fixed format approaches to rendering reports, such as the one described above, is that when templates are modified, the servers maintaining the templates must be taken out of service. As a result, the ability to produce clinical charts and provide medical providers access to patients' medical information is disrupted during the time the templates are being modified.
As can be seen, there are numerous limitations to the current fixed format approach described above. An alternative approach would be to utilize an architecture based on Extensible Mark-up Language (XML) and Extensible Stylesheet Language (XSL), in which an XSL stylesheet is written by a user and used to define the format for each report. An XML document is simply a document that uses mark-up tags to describe the data within the document. XML is human readable and can be easily modified with any standard text editor. XSL is a powerful language for transforming an XML document into another document. A formatted report could be produced by using a user-written XSL stylesheet, which contains formatting information, to transform an XML document, which contains report data. However, under this approach, a separate XSL stylesheet would have to be written for each report template. Because XSL is not generally human readable, this approach would require the user to be XSL savvy from the standpoint of writing the stylesheet, as well as reviewing and debugging the stylesheet. In addition, because XSL is dependent on the context of the surrounding code, storing different sections of the XSL file as separate XSL files that may be shared across multiple templates is not feasible.
Accordingly, a system for rendering reports, wherein the template for each report may be dynamically created from selected input parameters would be desirable. Further, it would be advantageous if the system permitted template modification while maintaining the ability to accurately render reports. In addition, a system in which sections may be shared among templates would also be advantageous. It would be further beneficial if the system employed a language that is human readable, making it conducive to reviewing and debugging.